feat: passthrough extra args for adk deploy cloud_run as Cloud Run args
#2544
Conversation
|
Response from ADK Triaging Agent Hello @jackwotherspoon, thank you for creating this PR! To help us review this PR, could you please address the following from our contribution guidelines:
You can find more details in our contribution guidelines. This information will help reviewers to review your PR more efficiently. Thanks! |
|
Please add testing plan(log or screenshot) |
|
Response from ADK Triaging Agent Hello @jackwotherspoon, thank you for updating the PR with a testing plan! Before this can be reviewed, could you please address the following:
You can find more details in our contribution guidelines. These changes are needed before the reviewers can proceed. Thank you! |
adk-bot
added
bot triaged
| called_kwargs = rec.calls[0][1] | ||
| extra_args = called_kwargs.get("extra_gcloud_args") | ||
| assert extra_args is not None | ||
| assert "--labels=test-label=test" in extra_args |
There was a problem hiding this comment.
where is adk-labels? could you assert that?
src/google/adk/cli/cli_deploy.py
Outdated
| user_labels_value = arg[9:] # Remove '--labels=' prefix | ||
| user_labels.append(user_labels_value) | ||
| else: | ||
| extra_args_without_labels.append(arg) |
There was a problem hiding this comment.
what if extra arg conflicts with existing args? raise error(other than the labels)?
|
@jackwotherspoon I see there is a merge conflict, could you help resolve? |
| @deploy.command("cloud_run") | ||
| @deploy.command( | ||
| "cloud_run", | ||
| context_settings={ |
There was a problem hiding this comment.
This would make it harder to maintain long-term.
I'd recommend adding a --gcloud_extra_arg option (with --multiple=True) to host.
Usage pattern could be --gcloud_extra_arg="--args1=val1" --gcloud_extra_arg="--args2=val2"
There was a problem hiding this comment.
This would make it harder to maintain long-term.
@Jacksunwei can you explain why this makes it harder to maintain...?
Seems way easier to maintain than the current approach of adding supported flags one by one.
There was a problem hiding this comment.
Usage pattern could be --gcloud_extra_arg="--args1=val1" --gcloud_extra_arg="--args2=val2"
From a DevX perspective I find this much worse than my current approach (in my opinion), you are asking folks to learn something new and have to do extra work to convert...
Versus telling folks to "take any of your existing Cloud Run deployments and copy your flags and just append them to your command".
The second option feels a bit more magical and it "just works"
There was a problem hiding this comment.
I think it makes things confusing. From user's perspective, when they do adk deploy cloud_run --arg1 val1 --arg2 val2.
There is no easy way to tell whether arg1 is for adk deploy cloud_run or for the underlying gcloud command.
User cannot have help text from adk deploy cloud_run --help, either.
It appears to be doing less things, but it will just confuse people and shut our door to provide any additional options in the future, because if gcloud also has an option of the same name, we may accidentally break users' existing setup.
There was a problem hiding this comment.
@Jacksunwei I think you may be mis-understanding...
Anything after AGENT_PATH is considered a gcloud arg, everything before is ADK flag...
# ADK flags
adk deploy cloud_run \
--project=$GOOGLE_CLOUD_PROJECT \
--region=$GOOGLE_CLOUD_LOCATION \
$AGENT_PATH \
# NEW gcloud run deploy flags
--min-instances=2 \
--no-allow-unauthenticatedThere is no easy way to tell whether
arg1is foradk deploy cloud_runor for the underlying gcloud command.
Yes there is, anything before AGENT_PATH is an ADK arg, if I try and add a gcloud flag before AGENT_PATH it will error:
Try 'adk deploy cloud_run --help' for help.
Error: No such option: --allow-unauthenticated
User cannot have help text from
adk deploy cloud_run --help, either.
Yes they can, adk deploy cloud_run --help, works fine. Only time it would potentially not work is --help after the AGENT_PATH.
because if gcloud also has an option of the same name, we may accidentally break users' existing setup.
This is a fair point, but do we really see this being the case...? Is there a plan to add a bunch more flags to adk deploy cloud_run? The benefits here seem to be huge.
The command
adk deploy cloud_runsupports limitedgcloud run deployargs 😢.Which makes the command fine for simple deployments...
It should support all current and future Cloud Run deployment args for the command to be widely adopted.
This can easily be done by passing through all extra args passed to
adk deploy cloud_runto gcloud...This PR assumes any extra args/flags passed after
AGENT_PATHare gcloud flags.Example
This gives full Cloud Run feature support to ADK users 🤖 🚀
Test Plan
To test you can just build locally or pip install feature branch directly:
Deploy to Cloud Run using additional arguments following
AGENT_PATH, such as--min-instance=2or--description="Cloud Run test":You can click on the Cloud Run service after deployment and check the service yaml, you should see the additional label etc.
Fixes #2351